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(57) Abstract 



A method and apparatus for providing enhanced communications services in conjunction with a communications network is disclosed. 
The method and apparatus includes collecting information in real-time concerning a transaction traversing the network (337) and storing 
the transaction information in a database (330). The method and apparatus also includes accessing the stored information from the database 
in real time (160). 
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ENHANCED VIRTUAL ACCESS SERVICES PLATFORM 

FIELD OF THE INVENTION 

The present invention relates to telecommunications and, more particularly, to a 
universal communication network platform providing services on a virtual basis, with 
integrated management, billing, and control capabilities at the transaction level. 

BACKGROUND OF THE INVENTION 

The U.S. telecommunications industry serves more than 90 million households 
and 25 million businesses (158 million lines), and generated revenues approaching $400 
billion in 1996. Technological advancement in this market, however, has been relatively 
slow, in part, due to a restrictive regulatory climate. Accordingly, the current 
environment evinces a number of serious shortcomings. 

Until 1984, telephone services in the United States were largely monopolized by 
AT&T. In 1984, AT&T was required to divest its local telephone systems, creating 
seven Regional Bell Operating Companies ("RBOCs"). The separation of the RBOCs 
from AT&T's long distance services created two distinct telecommunications market 
segments, local exchange and long distance. 

While vigorous competition existed in the long distance market, significant 
market entry barriers impeded the emergence of competition in the local exchange 
market. In addition to the large capital outlays required to build redundant competing 
networks, these market barriers include legally mandated local monopolies and the 
inability of competitors easily to interconnect with local exchange networks. 
Additionally, Incumbent Local Exchange Carriers ("ILECs") (including the RBOCs) 
often refused to "unbundle" their networks in order to provide third parties access to non- 
wire parts of their systems such as billing administration, network management and 
provisioning resources. 

The Communications Act of 1996 (the "Act") establishes a statutory program for 
the development of competitive local markets, with a particular emphasis on eliminating 
the entry barriers that have impeded local exchange competition. The Act contemplates 
three paths of entry into the local market: construction of new networks, the use of 
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unbundled elements of the incumbent's network, and resale. Today, under the Act, 
RBOCs may only offer long distance services within their respective local exchange 
regions if and when they satisfy the requirements of a 14-point checklist contained in the 
Act. Among other things, the RBOCs must prove that they face effective competition 
5 from facilities-based companies that use independent networks and switches to offer an 

alternate local service and that the RBOCs have offered competitors access to local 
services for resale at "fair and reasonable" resale rates, "unbundled" their networks to 
allow competitors to buy basic non-wire service elements (from which to build their own 
service packages), and established rules that allow competitors to interconnect to their 

10 network. 

In an effort to protect proprietary features of their networks, local exchange 
carriers have attempted to interpret the scope of the unbundling and interconnection rules 
narrowly. As a result, competitors have not been able fully to utilize the features of 
existing local exchange networks, thereby hampering competition and forcing new 

15 entrants to expend enormous amounts of time and capital to duplicate local exchange 

facilities. 

Another shortcoming in existing networks is the inability efficiently to link 
traditional narrow-band networks with newer, faster broad-band networks. Leased lines 
(or narrow-band lines), with their fixed point-to-point or multi-point configurations, have 
20 been the mainstay of data transport for many years. While dominant and still growing, 

leased lines have begun giving way to the faster, more economical packet-based higher 
bandwidth methods of moving data, such as cell or frame-based methods (broad-band 
lines). These are more efficient generally because they permit multiple users to share the 
same transport. 

25 Despite the clear advantages of broad-band technology in transporting voice, 

video and data information, to date, it has not been possible to establish a universal 
broad-band-based public switched network. Nor has it been possible to link such a 
broad-band network to existing narrow-band public switch networks. This is because the 
current public-switched network environment lacks the management, billing and control 

30 means necessary to operate such a network. 

Current networks also fail to utilize call processing information in the most 
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efficient manner. Conventional telephone switches transmit information required for 
processing telephone calls via normal voice trunk circuits using tones, simple relay logic 
or other electrical devices (i.e., in-band signaling). In contrast, Signaling System 7 
("SS7"), a more recently developed digital signaling system and the most common 
5 system used currently, carries processing information over data links separate from the 

voice trunk network - commonly referred to as "out-of-band signaling." By storing 
information, such as routing data, billing information and technical system data and 
controls at the service control point ("SCP") level, an SS7 network allows call set-up and 
routing to be accomplished independently of the voice circuits. The result is enhanced 

1 0 speed and efficiency of the telecommunications voice network. 

SS7 technology also allows a portion of the intelligence component of the 
telecommunications network to be removed from the physical switching apparatus and 
located in centralized Services Management System (SMS) databases. Messages, such 
as telephone number, calling card validation, 800 number routing, and calling name 

1 5 delivery are transmitted to signal transfer points ("STPs") that route the messages to the 

proper SCPs where call processing information is stored. These SCPs also house line 
information databases ("LIDBs") that provide billing and calling card validation, 800 
number portability, and other database services. 

Whether using conventional telephone switches or SS7 technology, current 

20 networks collect call processing information in a switch-centric, after-the-fact manner, 

capturing information pertaining only to a portion of the call transaction that was visible 
to the switch after the call entered the switch and before it was forwarded out of the 
switch. Traditional switches store the collected information as a Call Detail Record 
("CDR") in the local exchange carrier central office, typically on some magnetic storage 

25 medium (e.g., tape or disk). Although CDRs share many standard elements, each switch 

generates CDRs according to its own specific format, which may or may not correspond 
to the CDR format used in other switches. Thus, CDRs are archived in a dispersed, non- 
standardized, after-the-fact manner among numerous local switches such that it is not 
accessible or easily aggregated for real-time analysis or use in providing certain valuable 

30 services either to users or telecommunications providers, including network 

management, network engineering, billing administration, system administration or 
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resource provisioning. For example, if a caller wanted to investigate the history of a 
particular call to assess his billing obligations, the call information is not available in 
real-time. CDRs must first be recovered from storage within the local switches. That 
information is then forwarded to a billing interface processor where it is processed. It 
may take up to two billing cycles before the caller actually sees the desired billing 
information. 

Similarly, in the course of using SS7 technology, a substantial amount of 
transaction information such as data, billing information, and technical system data and 
controls passes through the system. Typically, such SS7 information is discarded 
entirely after the transaction occurs. While some SS7 networks and services are 
currently being implemented by companies utilizing certain SS7 processing information, 
such information has only been collected, stored and utilized in a relatively dispersed, 
switch-centric, fragmented manner. SS7 information has not been collected and stored 
for entire call transactions nor has that information been accessible in real-time to 
provide enhanced services to users. 

Another shortcoming of existing telecommunications systems is their inability to 
allocate bandwidth resources efficiently or accurately determine bandwidth usage. For 
example, a user of narrow-band leased lines is typically billed for the circuit capacity and 
the distance between the two points. When the circuit is not fully used, its idle capacity 
is unusable for any other purpose or customer. Additionally, there is no means to take an 
accounting of the bandwidth specifically used. 

The alternatives to leased lines are using packet networks such as Frame Relay 
and ATM. Even these broad-band networks, as currently implemented, involve charging 
the customer a flat monthly fee based on the bandwidth the customer desires - called a 
Committed Information Rate ("CIR"). Because the ability to track actual bandwidth 
used or the amount of data actually transported accurately is severely limited, any 
underuse of bandwidth (i.e., less than the CIR) cannot be credited to the user. Moreover, 
as the only transport bandwidth that is guaranteed to the customer is the original CIR, the 
customer can actually use more bandwidth than was contracted for up to their Peak 
Information Rate ("PIR") only if more bandwidth is available on the network. 

Accordingly, there is a need for an improved telecommunications system which 
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will allow local exchange carriers to comply with the Act without compromising their 
proprietary network information or imposing large capital outlays and time delays on 
new entrants. Furthermore, there is a need for an improved telecommunications system 
which serves as a universal interface between narrow-band and broad-band networks. 
5 There is also a need for an improved telecommunications system that can access, 

aggregate and analyze call processing information in a more timely and efficient manner. 
Finally, there is a need for an improved telecommunications system that can efficiently 
allocate and track the use of bandwidth resources. 

1 0 SUMMARY OF THE INVENTION 

According to the invention, the system for providing telecommunications services 
offers substantial improvements over prior systems. A wide variety of embodiments of 
the present invention exist and will be understood by those skilled in the art based on the 
present disclosure. Certain embodiments of the present invention offer services on a 

1 5 virtual basis with integrated management billing and control capabilities. Certain 

embodiments of the invention support bandwidth-on-demand services. Certain 
embodiments of the invention enable remote Service Management System ("SMS") 
database access. Certain embodiments of the invention provide a way for ILECs to 
comply with the Act in an efficient and secure manner. Certain embodiments serve as a 

20 universal interface between narrowband and broadband networks. These and other 

embodiments of the invention will be understood by those skilled in the art based on the 
present disclosure. 

Certain embodiments of the invention offer many advantages including, without 
limitation, the following: 
25 • a system providing narrow to broadband internetworking; 

• a system for efficiently using existing ATM transport bandwidth; 

• a system for provisioning accurate bandwidth-on-demand; 

• a system enabling billing based on the actual bandwidth used and the actual 
amount of data transported; 

30 • a system for collecting all detailed records concerning transactions and 

converting the data to customer required CDRs in real time; 
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• a system providing customer access for such functions as real-time billing 
data, network status, Primary Interexchange Carrier/Customer Account 
Record Exchange ("PIC/CARE"), and customer updates to the SMS database; 

• a system supporting real-time network engineering and management, 
subscriber and customer service provisioning, and billing and system 
administration; 

• a system for providing Mediated Access Services ("MAS"), which allows 
carriers and service providers to exchange key information without 
compromising their proprietary databases; 

• a system for transporting voice, data, video, and other services on one 
network; and 

• a system for providing fixed-segment services (e.g., permanent virtual circuits 
O'PVCs") and soft permanent virtual circuits ("S-PVCs")) on demand. 

These and many other advantages of certain embodiments of the invention will 
become apparent to those skilled in the art from the detailed description below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

An understanding of one or more embodiments of the invention may be gained by 
considering the following detailed description in conjunction with the accompanying 
drawings, in which: 

FIG. 1 illustrates a high level diagram of a portion of a communication network 
incorporating an embodiment of the invention. 

FIG. 2 shows an embodiment of an Element Manager. 

FIG. 3 shows an embodiment of a Master Service Management System. 

FIG. 4 shows an embodiment of an Interface Element Manager. 

FIG. 5 illustrates an example of how a call flows through the network from origin 
to destination in an embodiment of the invention. 

FIG. 6 illustrates an example of server architecture and switching center 
configuration in an embodiment of the invention. 

FIG. 7 illustrates an example of a typical data transmission pattern over time in an 
embodiment of the invention. 

FIG. 8 illustrates an example of the communication architecture in an 
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embodiment of the invention. 

FIG. 9 illustrates an example of mediated access services in an embodiment of 
the invention. 

5 DETAILED DESCRIPTION 

FIG. 1 illustrates a high level diagram of a portion of a communication network 
incorporating an embodiment of a Virtual Access Services Platform ("VASP") system 
according to the present invention. The VASP system is used to build a broadband 
communication network, as might be operated by a service provider, that is referred to 

10 herein as a "network/* 

Using certain embodiments of the VASP system, traditional narrow-band 
networks can be efficiently linked with newer, faster broad-band networks. VASP 
system components, referred to as element managers, perform the system functions to 
achieve this link. The various element managers are discussed in detail below. 

15 Using certain embodiments of the VASP system, a mediating carrier (i.e., neutral 

third party) could support the exchange of key information between subscribing carriers 
and service providers, without compromising their proprietary databases. As described 
below, access to data stored in a mediating carrier's master relational database could be 
regulated through the definition of views. For example, a subscribing carrier could view 

20 data relating to the subscribing carrier's customers, and a providing carrier could view 

data relating to the providing carrier's equipment. The subscribing carrier and the 
providing carrier, however, would not be able to view each other's data. 

Certain embodiments of the VASP system support enhanced services. One 
enhanced service is a telecommunications voice network with increased speed and 

25 efficiency. By canying call processing information over data links that are separate from 

the voice trunk network, call set-up and routing is accomplished independently of the 
voice circuits. Another VASP system enhanced service is network provisioning. As 
described below, a service provider would have more detailed data than is typically 
available regarding available network capacity and network usage. Using this detailed 

30 data, a service provider could allocate bandwidth resources efficiently and could 

accurately determine bandwidth usage. This would allow the service provider to 
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maximize the use of a given line and to bill for the actual bandwidth used, based on the 
actual amount of data transported. 

Referring to FIG. 1, the VASP system comprises three logical components: an 
Element Manager ("EM") 101, a Service Management System ("SMS") 305, and an 
5 Interface Element Manager ("IEM") 405. Each of these components is described briefly 

now, with detailed descriptions provided in the following sections. 

As illustrated in FIGS. 1 and 2, the first VASP component, EM 101, is a set of 
"element managers." Element managers perform many VASP system functions such as 
interfacing, protocol conversion, and general management and control. EM 101 includes 

10 a Signaling Element Manager ("SEM") 1 10, a Master Element Manager ("MEM") 105, 

and a Transport Element Manager ("TEM") 115. SEM 110 manages the signaling layer 
of the network via legacy SS7 and other advanced signaling protocols, while TEM 115 
manages the transport layer of the network via legacy interfaces (DS-0 through OC-12) 
to the ATM network. MEM 105, located between SEM 1 10 and TEM 115, executes 

15 service logic and functions, as well as manages the communication and synchronization 

functions of SEM 110 and TEM 115. In some embodiments EM 101 also includes 
additional element managers to perform other functions, such as an Intelligent Peripheral 
Element Manager ("IPEM") to handle voice processing (e.g., voice recognition and tone 
playing). 

20 As illustrated in FIG. 3, the second VASP system component, SMS 305, provides 

support for various VASP system functionality. This functionality includes several SMS 
applications 325 such as billing administration 335, network management 337, service 
provisioning 339, network engineering 341, and system administration 343. SMS 
applications 325 access data in a master SMS database (e.g., Master SMS DB 330) via 

25 Data Access Layer 160. Both Master SMS DB 330 and Data Access Layer 160 are 

discussed below. 

As illustrated in FIG. 4, the third VASP system component, IEM 405, manages 
the interface layer for systems that interface with Master SMS DB 330. Managing the 
interface layer includes enabling and disabling a particular interface and regulating which 
30 systems are connected. External systems interface 482 manages the flow of information 

to and from external systems 480. User interface 472 provides access to SMS 
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applications 325 from client 470. IEM 405 is described in further detail below. 

TECHNICAL ARCHITECTURE 
SS7 Interface 

5 Referring to FIG. 2, SS7 interface 224 performs the tasks of managing the 

connection and transporting messages between SS7 network 220 and MEM 105, as 
follows. Incoming ISDN User Part ("ISUP") messages pass via an A-link through ISUP 
interface 222 to SS7 interface 224. SS7 interface 224 extracts the details (e.g., 
parameters) from the messages and passes these parameters to MEM 105 for processing. 

10 For outgoing messages, SS7 interface 224 receives the parameter values from MEM 105 

and constructs the ISUP messages to be forwarded through ISUP interface 222 to SS7 
network 220. SS7 interface 224 uses commercially available DGM&S OMNI software 
that supports all layers of the SS7 protocol and which runs in an active/backup fault 
resilient mode. As those skilled in the art will appreciate, the SS7 interface could use 

15 any software based on an industry standard SS7 protocol API (e.g., as would be provided 

by Trillium Digital Systems Inc.). 

ATM Interface 

Referring to FIG. 2, ATM interface 234 performs the tasks of managing the 
20 connection and transporting messages between TEM 115 and ATM node 230. As those 

skilled in the art understand, most networks would contain more than one node. 
Messages are transmitted between TEM 115 and ATM node 230 using the Simple 
Network Management Protocol ("SNMP") protocol, via Ethernet and IP relay. ATM 
interface 234 is responsible for constructing the outgoing SNMP protocol messages 
25 based on the parameters sent from TEM 115 and for decoding the incoming SNMP error 

and status messages. The SNMP messages pass from ATM interface 234 through SNMP 
Manager 232 to ATM node 230. SNMP Manager 232 can be implemented with a public 
domain SNMP library. 

30 Data Access Laver 

As will be understood by those skilled in the art based on the present disclosure, 
Data Access Layer 160 is a generic data access API and various VASP system 
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components have their own instances (i.e., copies) of Data Access Layer 160. For 
example, as illustrated in FIG. 1 and FIG. 3, an instance of Data Access Layer 160 sits 
between SMS applications 325 and Master SMS DB-A 620. The inquiry and update 
calls to Master SMS DB-A 620 are encapsulated using the Oracle Call Interface ("OCT"), 
5 with the communication with Master SMS DB-A 620 taking place over a TCP/IP 

LAN/WAN, using SQL*Net as middleware. 

Another example of Data Access Layer 160 is illustrated in FIG. 2. In this 
example, an instance of Data Access Layer 160 sits between a distributed EM database 
(e.g., EM DB 210 (described below in the section entitled "Data Distribution") and the 

10 MEM 105 and TEM 115 components of EM 101. 

In a conventional manner, Data Access Layer 160 provides firewall security, 
transaction benchmarking, and change flexibility (e.g., for SQL code). Data Access 
Layer 160 also isolates the Oracle Call Interface and SQL code from VASP system 
application code. This reduces the complexity of integrating SQL code with application 

15 code and enables significantly easier and more timely maintenance of the VASP system. 

User Interface 

User interface 472 is a graphical user interface ("GUI") that provides access to 
SMS applications 325 (discussed below) from client 470. Client 470 can be any 
20 appropriate platform, including the Windows95, Windows NT 4.0, and Java platforms. 

As would be understood by one skilled in the art, user interface 472 could be any 
appropriate type of interface (e.g., voiced command or menu based) running on any 
appropriate platform (e.g., OS/2 or Unix). 

25 External Systems Interface 

External systems interface 482 manages the flow of information to and from 
external systems 480. External systems interface 482 allows external systems 480 to 
access Master SMS DB 330 for managing the flow of information to and from 
Subscribing Carriers; Customer Care and Billing Systems; and other providing carriers, 

30 provisioning centers, and information sources (e.g., NPAC and Bellcore Local Exchange 

Routing Guide ("LERG")/LIDB Access Routing Guide ("LARG"). Examples of the 
communication with external systems 480 also include EDI, data transfer with external 
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systems, and messaging with network equipment. 

Network Element Management Interfaces 

The interfaces to network elements (e.g., STP, 600E switches) support the 
operation, maintenance, administration, and provisioning (i.e., OAM&P) functions 
required for proper operation of the network. These functions include error monitoring, 
status monitoring, and control operations not supported by the SS7 and ATM Interfaces. 
These interfaces are not specific to the VASP system. Rather, these interfaces are either 
standard interfaces or interfaces that are proprietary to an equipment provider. Those 
skilled in the art would be familiar with management protocols, such as Common 
Management Information Protocol ("CMIP"), Simple Network Management Protocol 
("SNMP"), or Transaction Languagel ("TL1"). 

VASP APPLICATION ARCHITECTURE 

This section refers to several system components that are discussed further herein. 
One component, an "EM server," supports several VASP system processes and the 
associated data storage. The other components, the "ATM backbone" and "switching 
centers" are generally known to those skilled in the art. Switching centers contain the 
equipment responsible for routing information from the point of origin to the destination. 

MEM 

The network is controlled by one EM server (e.g., EM server- A 605). In certain 
embodiments, the EM server is located in a Chicago switch center, with a backup located 
in a New York switch center (e.g. , EM server-B 625). Class 4 switch functionality is 
built into MEM 105, which performs SS7 message routing, destination routing logic, and 
transaction logging. All call transactions in the network, whether transported over the 
ATM backbone or not, are handled by the single EM server. 

Within the SS7 network, MEM 105 is represented as a distinct signaling node, to 
which ISUP messages are routed from either the Access Tandem switches that are 
serviced by the network, or by 600E switches located within the switching centers. In 
the basic call model for this architecture, MEM 105 will process all ISUP messages, 
originating messages from Access Tandems, inter-network messages between 600Es, and 
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terminating messages to Access Tandems or third-party service providers. For example, 
the IAM message for a call from New York to Chicago, transported over the ATM 
backbone, would be routed in the following sequence: ATNY - MEM - 600ENY - MEM 
- 600ECHI - MEM - ATCHI, where AT refers to an Access Tandem switch. In 
performing this routing activity, MEM 105 performs a database lookup, translating the 
actual called party number to a Virtual Routing Number ("VRN")* The VRNs serve to 
remove call routing logic from the 600E switches and place this logic in MEM 105. 

The basic call model example, described above, represents the base set of service 
logic that resides on MEM 105. As will be understood by those skilled in the art based 
on the present disclosure, the present invention permits additional modules of service 
logic to be incrementally added to MEM 105 to support the following services: 
Basic Call(l+) 
800/888 
10XXX 
International 

Operator Services (0 & 00) 
0+ 

Calling Card 
NPA-555 
Dedicated Voice 

Throughout the life of a call, MEM 105 logs the circuit-related ISUP messages 
that it receives, as well as the transaction data, such as timestamps used for billing 
purposes. Since MEM 105 components can process a call transaction at more than one 
point for each ISUP message, multiple message and transaction log entries are generated. 
A summarization function takes place within SMS 305 to deliver the billing 
functionality. 



30 



TEM 

In a conventional manner, TEM 115 manages call traffic that is carried over the 
ATM backbone trunks and sets up and tears down bandwidth in response to changes in 
the traffic flow. The 600E switches in the network preferably are configured such that 
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the circuits and ports used are selected in a specified order. Because of this, the number 
of calls out of each switch port can be tracked, and when a threshold point is reached, an 
additional ATM backbone trunk can be dynamically configured in preparation for the use 
of an additional switch port. In order to speed up the processing time, the data used by 
TEM 115 during the backbone management and virtual trunk set up and tear down is 
referenced from static, memory resident, data structures in memory resident data 205. 
Additionally, TEM 115 responds to the incoming error and status messages received 
from the BPX switches. As will be understood by those skilled in the art, TEM 1 15 
functionality described in this section is common in communication networks. 



SEM 

SEM 1 10 manages the signaling layer of the network via legacy SS7 and other 
advanced signaling protocols. Those skilled in the art would be familiar with signaling 
protocols, such as ISDN User Part ("ISUP"), Transaction Capabilities Application Part 
CTCAP"), Message Transfer Part ("MTP"), and Signaling Connection Control Part 
("SCCP"). In some embodiments the TR-303, Q.931, and Q.2931 signaling protocols 
arc used. 



IFM 

IEM 405 is the generic interface between Master SMS DB 330 and external 
systems or customers (e.g., subscribing carriers) and facilitates the transfer of 
information into and out of Master SMS DB 330. Referring again to Fig. 4, IEM 405 
comprises user interface 472 accessible to clients 470 and external systems interface 480 
accessible to external systems 480. IEM 405 further includes data transform 
function 488 that translates incoming data received from external systems 480 or 
clients 470 into formats compatible for use within Master SMS DB 330 and transforms 
outgoing data from Master SMS DB 330 into formats compatible for use by clients 470 
or external systems 480. Data transfer function 484 facilitates the movement of 
incoming and outgoing data to and from data transform function 488 to its final 
destination. Data audit function 486 checks data translated by data transform 
function 488 to ensure that the data has been converted to a form usable by the 
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destination system (i.e., Master SMS DB 330, clients 470 or external systems 480). 

IEM 405 provides the customer interface to the communication network for such 
functions as real-time billing data, network status, Primary Interexchange 
Carrier/Customer Account Record Exchange ("PIC/CARE"), and customer updates to 
5 Master SMS DB 330. It also is used to collect Transaction Detail Records ("TDRs") 

from Master SMS DB 330, converts TDRs to client/subscribing carrier required Call 
Detail Records ("CDRs"). TDRs and the creation of customer CDRs are more fully 
described below in conjunction with the Master SMS DB 330. 

Data interfacing and interpretation between central databases and external 
10 systems is well-known to the art. The generic functionality of IEM 405 described above 

may be achieved using those prior art means. 

SMS Applications 

SMS applications 325 access Master SMS DB 330 to support internal VASP 
1 5 system functionality. This functionality is primarily implemented through the use of 

TDRs and falls into broad categories such as Billing Administration, Network 
Management, Service Provisioning, Network Engineering, and System Administration. 
Examples of functionality in each of these categories are provided below. As those 
skilled in the art understand, SMS 305 can easily support additional functionality, such 
20 as Trouble Management, PIC/CARE, and telephone number-based long-distance debit 

services. 

Transaction Detail Records ("TDRs") 

25 TDRs are defined as the real-time collection of network transaction information 

(e.g., network signaling messages, access/transport/exit routing information, network 
resource usage and consumption data, etc.) that can be used for providing enhanced 
functionality such as resource provisioning, control of AIN services, billing and 
maintenance of those services, and network management. Preferably, TDRs encompass 

30 information traditionally generated and contained in CDRs and also include information 

generated in the course of using SS7 technology and other network signaling technology 
(e.g., SNMP) and additional relevant transaction information about messages traveling 
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through the VASP system. Thus, in contrast to CDRs and other switch-centric 
collections of call processing information, TDRs include information relevant to the 
entire transaction, not just the fragment available to a particular switch. This is possible 
because embodiments of the present invention are able to "see" and control the entire 
network transaction from beginning to end. 

In one embodiment, TDRs comprise a collection of data tables making up a 
highly normalized relational database within Master SMS DB 330. Using data structures 
and methods known in the art, transaction processing information is collected in real- 
time and stored in a standardized format in this database. Moreover, the transaction 
information may be analyzed to derive other information that may be stored in TDRs. 
For example, the transaction processing information may be taken from TDRs, used to 
determine error conditions and the error condition information can then also be collected 
in TDRs. 

The following is a representative list of some types of information collected and 

stored in TDRs although those skilled in the art will appreciate that there are numerous 

other types of information that may be stored in TDRs which could be useful in the 

provision of communications services: 

Network Signaling Messages: time of transaction, type of message, and 

optional parameters such as calling number, 
dialed number, charge number, and ported 
number; 

Routing Information: access and exit paths, transport paths, trunk 

and circuit connections, and re-routing 
information; 

Network Resource Usage: circuit bandwidth used and processing 

elements (SEM, TEM, etc.) used; 

Additional Information: error conditions regarding the transaction, 

originating carrier, originating city; total 
connection time, and type of information 
transmitted (i.e., voice, data, video). 

The real-time collection of information in TDRs allows for real-time analysis and 
acquisition of the information. Using the information in TDRs, one can see the status of 
a call in progress and assess the route that call has traveled within the system. By 
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collecting the above types of information in real-time as taught herein and analyzing it, 
one skilled in the art would be able to determine patterns in the information, derive 
important details about the transactions (e.g., the message failed to route, there was no 
answer, the answer was incomplete, the address was incomplete, etc.) and define 
relationships within the TDR database that allow for the provision of enhanced 
communications services. For example, the table below illustrates the relationship 
between Access ("A"), Transport ("T"), and Exit ("E") SS7 routing messages collected 
for each transaction in the TDRs and the status of transactions, individually and overall, 
tn the network. This table represents a report that may be routinely generated for the 
purpose of assessing and maintaining the network. 



NETWORK HEALTH REPORT 
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Transactions 
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Trans. 


Status 
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133 
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ACCESS Hub Failed to Route 
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1 


1 


312 


29.4 


Backbone Switched Calls 
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Reroute TRANSPORT 
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.1 


Reroute TRANSPORT, EXIT 








1060 







As discussed above in conjunction with the IEM 405, the information from TDRs 
may be used to create CDRs for use by customers because TDRs either directly include 
the information traditionally contained in CDRs or may be used to derive the required or 
surrogate CDR information. Furthermore, as TDRs are standardized internally and 
encompass call processing information for entire transactions, a customer may be 
efficiently provided with CDR information for entire transactions in a CDR format of the 
customer's choosing. Currently, CDR information for an entire transaction may only be 
obtained by the extremely slow and inefficient procedure of collecting the non- 
standardized CDRs from each switch involved in that transaction and translating the 
CDRs into a format usable by the customer. 
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Similarly, the real-time accessibility of TDR information and control of the entire 
network transaction allows for efficient service provisioning. One strength of the present 
invention is that it allows for the efficient control and use of network resources by 
providing enough bandwidth for any overflow traffic. Embodiments of the present 
5 invention are capable of controlling the ATM switches and, via TDRs, the real-time 

utilization of the network trunk and its routing. By monitoring network traffic in real- 
time, the system is able dynamically to route overflow traffic to other paths on the 
network, and consequently process data that would be lost with normal ATM switching 
in the prior art legacy network environment. For example, referring to FIG. 7, the graph 

1 0 depicts a typical data transmission pattern over time. All traffic up to the Sustainable 

Cell Rate ("SCR") 705 is processed without delay. In Bl 740, because of the short 
duration of the burst, all traffic up to the Cell Delay Variation Tolerance ("CDVT") 710 
is processed with the segment above, Discarded segment 715, being lost. In B2 745, all 
traffic up to the Peak Cell Rate ("PCR") 720 whose duration is less than the Maximum 

1 5 Burst Size ("MBS") 725 is admitted (Admitted segment 730). That traffic exceeding 

MBS 725 is tagged (Tagged segment 735) and could be discarded. Utilizing the VASP 
system technology solution, the management function would permit all but the excess 
bandwidth above CDVT 710 to be processed. This proactive approach preempts the- 
discarding of any cells. The VASP system technology controls how such traffic is 

20 optimized on the ATM network and dynamically allocates bandwidth-on-demand. The 

result is the ability to offer an almost guaranteed network bandwidth availability to it 
users. These and other enhanced services enabled through the use of TDRs are further 
discussed below. 

25 Billing Administration 335 

• Master SMS DB 330 is the master data repository of all network transaction 
information. 

30 • Manages the flow of data, such as billing data to wholesale billing systems and 

subscriber customer CDRs to subscribing carriers. 

• Provides for the management of transaction record summarization, archival, and 
deletion. 
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Network Management 337 

• Analyzes transaction and error data collected from network components. 

• Provides a network control center with the capability to monitor and control 
network equipment, facilities, routes, and systems. 

• Provides a network control center with reports and alarms for managing the 
network. 

• Provides for the management of error record summarization, archival, and 
deletion. 

Subscriber and Customer Service Provisioning 339 

• Provides an interface to manage the subscribing carriers' records and services 
provided to their customers. 

• Provides import capabilities for subscribing carrier customer service requests 
(i.e., orders) and the user interface for manual input of orders. 

• Provides reports for service provisioning administration and order error 
resolution. 

Network Engineering 341 

• Provides an engineering interface to configure locations, equipment, routes, 
facilities, services, and systems. 

• Includes import and provisioning for Bellcore LERG/LARG data and Regional 
NPAC local portability subscription data. 

• Provides usage reports for engineering inventory, capacity management, and 
growth planning. 

System Administration 343 

• Provides user and system security administration. 

• Provides database maintenance interface for analyzing and maintaining VASP 
system data tables. 

• Provides reports for VASP system application transaction and administration 
tools. 
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Mediated Access Services 

In certain embodiments that will be understood by those skilled in the art based 
on the present disclosure, the Master SMS DB 330 is used in the provision of Mediated 
Access Services in the telecommunications industry. This capability provides neutral 
"third-party" access to the various SMS databases throughout the industry. For example, 
in a mediated access services system, any service provider (virtual or facilities-based) 
will be able to obtain the key call treatment information necessary to properly process its 
customers' calls while the proprietary information of the database owner is protected 
from compromise. For example, a requirement for mediation results from the FCC's 
Local Number Portability (LNP) order. That order requires the RBOCs and GTE to 
provide their customers who desire another competitive carrier the ability to change local 
service providers within the exchange and retain their same telephone number. 

Mediated Access Services will greatly improve the LECs capability to offer 
unbundled local service elements to other carriers in compliance with the requirements of 
the Telecommunications Act. Mediated Access Services also provides a beneficial 
solution for unbundling the local exchange network and promoting local service 
competition. 

Referring now to FIG. 9, Subscriber 905 (a subscribing carrier) interfaces (via 
IEM 405 - not shown) with Master SMS DB 330 to place orders for voice/data services 
on behalf of its customers. The interface also allows Subscriber 905 to obtain real-time 
status information and CDRs (to effectuate billing administration) regarding its orders 
from Master SMS DB 330. Similarly, Provider 910 (a providing carrier) is linked to 
Master SMS DB 330 to receive queries regarding service requests and to provide status 
information back to Master SMS DB 330. Provider 910 includes a service provider 
database. 

The mediating role is effectuated by restricting access to data stored within 
Master SMS DB 330 through the definition of views. For example, Subscriber 905 will 
only have access to the data that pertains to its network equipment and call traffic. 
Provider 910 will have access to the data that pertains to its network equipment, but not 
to the details about the call traffic that is carried on the equipment. Call traffic data is 
available in summary form only. The VASP system, via the Master SMS DB 330, has 
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access to, and is able to maintain, all of the data on the network. 

Master SMS DB 330 receives the Calling Party Number ("CPN") from 
Subscriber 905, and, using its class of service information, identifies the appropriate 
Provider 910. The query is then routed to the Provider 910 service provider database 
where the details of the customer and services are maintained. Provider 910 then 
generally provides the services directly to customers of Subscriber 905, under the brand- 
name of Subscriber 905. 

Embodiments of a mediated access services system permit LEC Providers 910 to 
offer fully unbundled local exchange capabilities, utilizing existing network facilities and 
switches, while protecting access to their proprietary and customer databases. In this 
multi-layered architecture, the Master SMS DB 330 contains only the logic required to 
control the basic service elements. All carrier and customer-specific data are maintained 
externally. 

Responses to the local switch queries instruct the switch how to apply the next 
local service elements without disclosing the nature of the service, or identifying the 
customer being served. This architecture provides a full set of local switching 
capabilities to external service providers without the cost of owning and operating a local 
switch, while maintaining complete isolation of the Subscriber 905 and Provider 910 
databases. The net result of this multi-layered service offering is that it enables any 
service provider, that elects to use the capabilities, the potential to become a virtual 
carrier. Competitive providers then have the ability to offer the same types of services 
presently available only from the IXCs and LECs. 

BASIC CALL MODEL FLOW 

Given a communication network based on a VASP system according to the 
present invention, the following describes a "Basic Call Model" in terms of a typical two 
party voice call. The model holds for two party calls with bit rates for voice, data, and 
video. However, the bit rate of the media must match the bit rate of the signal, Le. 9 
standard DS-0 trunks used for voice rate signals cannot handle video signals. 

Each call requires communication and signaling facilities that provide a path for 
voice signals and call control signals respectively. EM 101 call processing allocates 
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media (i.e., facilities or trunks to carry the communication signals, such as voice signals 
in this case) between the parties of a call. Trunks are allocated on a per call basis. 
Signaling links carry out-of-band call control messages between the signaling and 
switching components of the system. Owing to the nature of common channel signaling, 
5 the signaling channels are separate from the communication channels. Signaling links 

process all messages to and from a signaling point according to a load sharing 
mechanism inherent in the link and network level protocols of SS7. 

The Basic Call Model consists of three portions, an originating portion, a 
terminating portion, and, as required, a transport portion. For a VASP-enabled network, 

10 each of these portions of the call also has originating and terminating portions. Each 

portion appears to the switching and signaling components, as unrelated calls segments. 
One of the functions of the service logic in EM 101 is to analyze and manipulate 
signaling messages to provide correlation between the call segments. A similar function 
is performed by the SSPs (e.g., SSP1 517 and SSP2 533) for the calls they process. This 

15 correlation function is common to switching systems, although the implementation 

varies. 

Access trunks are associated with the originating call portion, and exit trunks are 
associated with the terminating call portion. Transport trunks, also called backbone 
trunks, are associated with the transport portion. One of the functions of EM 101 call 

20 processing is to "switch," that is, to cross-connect access trunks to exit trunks to create an 

end-to-end path over which communication between users takes place. Under certain 
circumstances, a transport trunk may be required to effect the requested cross-connection. 
Trunks are normally configured as a two-way medium. This means that for different 
calls, the same trunk may be used as either an access trunk (originating) or an exit trunk 

25 (terminating). 

Referring to FIG. 5, access and exit trunks (e.g., access-exit trunks 553) consist of 
sections of DS-1 (1.544 Mbps) Time Division Multiplexed ("TDM") media configured 
for SS7 and Feature Group D ("FGD") operation. Transport trunks consist of sections of 
DS-1 TDM media (e.g., transport trunk 555) and DS-3 or OC3 ATM media (e.g., 

30 transport trunk 557) configured for SS7 and inter-machine operation. 

Service Access Modules ("SAMs") (e.g., SAM 519 and SAM 531) adapt the 
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TDM network to the ATM network with circuit emulation functions that maintain frame 
synchronization of the TDM Inteimachine Trunk ("IMTs"), and convert TDM signals to 
ATM signals and vice versa. Circuit emulation functions are used because of differences 
in the transmission and timing characteristics between TDM and ATM. TDM is a 
5 continuous, nearly synchronous, frame-based transmission mode, and ATM is 

synchronously or asynchronously timed, packet-based transmission mode. These 
dissimilar modes of transmission cannot be directly inter-connected. 

SAM media interworking converts TDM signals (channels and frames) to ATM 
signals (53-byte cells) and vice versa. Additional SAM functions provide loopback 
1 0 connections on the SAM TDM ports that maintain timing synchronization in the absence 

of connections on the corresponding ATM virtual circuits ("VCs"), such as is the case 
when the TDM circuits are not in use. 

Current networks utilize two primary trunk transmission configurations, end-to- 
end TDM sections, or TDM sections cross-connected by ATM permanent virtual circuits 
15 ("PVCs"). In the first configuration, TDM paths between two switching points are 

terminated by digital transmission equipment at the switches. The digital transmission 
equipment maintains timing and frame synchronization required for proper operation of 
the end-to-end TDM circuit. 

In the second configuration, TDM circuits are terminated by circuit emulation 
20 service modules of an ATM node are and cross-connected by an ATM permanent virtual 

circuit, i.e., a virtual circuit that is pre-configured and always "connected." The result is 
an end-to-end frame synchronized TDM path. The ATM cross-connect section is 
transparent to the TDM portion of the path. In these two configurations the paths are 
present whether or not calls are active on the trunks. ATM resources associated with the 
25 cross-connects are dedicated to the PVCs and are not available for allocation to other 

services or applications, not even for other cross connects (in a typical application). 

The trunk configuration of a VASP-enabled network is similar to the second 
configuration except that the ATM virtual circuits are created on demand, as required to 
cross-connect TDM access and exit trunks when calls are active on the trunks. VASP 
30 virtual circuits are so-called "soft" PVCs ("S-PVCs"). S-PVCs differ from PVCs in that 

the request for a S-PVC requires only the endpoints of the VC at the time of the request. 
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A protocol in the ATM backbone network determines the path for the VC. The ATM 
nodes may dynamically adjust the path depending on factors, such as bandwidth 
demands of other applications. The S-PVCs are configured with capacity to carry one 
DS-1, i.e., 24 TDM channels (1.544 Mbps). The VASP system currently uses an S-PVC 
5 capacity of DS-1 because that is the level of channelizing available in the SAMs; 

however S-PVCs may be configured for capacity of DS-0, DS-1, or DS-3 (higher for 
optical media) if the proper channelizing is available in the SAMs and ATM nodes. DS-0 
channelization is preferred for voice applications. DS-1 multiples up to DS-3 are 
suitable for data and other non-voice applications. The S-PVCs are torn down when 

10 there are no calls on the associated TDM trunks. When the S-PVC is torn down, the end- 

to-end path no longer exists, resulting in a loss of frame synchronization on the 
associated TDM circuits. To maintain synchronization, TEM 115, managing the ATM 
trunks, applies a loopback connection to endpoints of the ATM VC, which causes the 
associated TDM channels to maintain frame synchronization. The loopback connection 

1 5 is removed by TEM 115 logic during call setup when the TDM trunk is to be used in a 

call. 

When there are no calls on a virtual circuit, its ATM resources can be allocated to 
other services or applications. This results in more efficient use of ATM resources 
because resources are not consumed when there is no demand (traffic). The operator of a 

20 VASP-enabled network can "over subscribe" the services of the network, that is, offer 

more services than can be handled simultaneously by the available ATM resources 
(bandwidth); however, as expected, all services can not be requested at once. 

An SS7 link 551 is a signaling link that carries Common Channel Signaling 
Number 7 ("SS7") ISDN User Part ("ISUP") messages. Signaling links are sections of 

25 TDM media operating in a dedicated or "clear channel" mode of 56 or 64 KB/s. Higher 

rates (e.g., 1.544 MB/s) may be used for signaling links between EM 101 signaling 
points within a VASP-enabled network; however, standards for high-speed links are not 
mature for general use in public networks. SS7 ISUP messages to setup and tear down 
calls are exchanged over SS7 links 551 that run between signal transfer points (e.g., 

30 STP-A 501 , STP-B 503, and STP-C 505), as well as between signal transfer points and 

Access Tandems (e.g., AT 515 and AT 535), service switching points (e.g., SSP1 517 
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and SSP2 533), and EM 101 components (e.g., SEMs). 

There are variants for national and international applications of ISUP. EM 101 
components are programmed to use the ANSI 88, 92, or 96 variants of the ISUP 
protocol. ANSI variants are used mainly in North America. EM 101 components can be 
5 programmed to use most of the ISUP variants in use nationally and internationally. The 

various EM 101 element managers (e.g., MEM 105, access SEM 123, exit SEM 125, and 
TEM 1 15) communicate over TCP/IP connections, such as TCP/IP paths 120. SEM 110 
was described generally in connection with FIG. 1. Embodiments of SEM 1 10 include 
originating SEMs (e.g., access SEM 123) and terminating SEMs (e.g., exit SEM 125). 

10 A H SS7 nodes (signaling points) are assigned addresses called point codes that 

allow nodes to designate and identify one another as the source or destination of 
messages. The source of an ISUP message is the Originating Point Code ("OPC"); the 
destination is the Destination Point Code ("DPC"). As SS7 nodes, each AT (e.g., 
AT 515, AT 535), SSP (e.g., SSP1 517, SSP2 533), SEM (e.g., access SEM 123, exit 

15 SEM 125), and TEM 1 15 is assigned a point code. Within a VASP-enabled network, the 

point codes assigned to access SEM 123 and exit SEM 125 are visible to the external 
SS7 network; TEM and SSP point codes are not. The VASP system logic determines 
how messages received from external networks are routed between signaling points 
within the network. Within a VASP-enabled network, SEM and TEM point codes are 

20 known to SSPs (e.g., SSP1 517, SSP2 533). 

Access SEM 123, exit SEM 125, and TEM 1 15 are signaling points that receive, 
interpret, manipulate, and transmit ISUP messages. The SEMs and TEM write the ISUP 
messages to transaction files in a format understood by an IEM 405 transaction reader. A 
transaction reader parses the message files and writes out the messages to Master 

25 SMS DB 330. These messages are the foundation for the VASP system transaction 

detail records ("TDRs"). SMS applications 325 process ISUP messages to enhance 
service management functions, such as billing administration 335, network 
management 337, service provisioning 339, network engineering 341, and system 
administration 343. Access SEM 123 and exit SEM 125 process ISUP messages 

30 associated with the access trunks between SSPs and Access Tandems. TEMs process 

ISUP messages associated with transport trunks 557 between the SSPs (e.g., SSP1 517, 
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SSP2 533). SEM and TEM components maintain mapping of AT and SSP point codes 
and circuit identification codes ("CICs") of the trunks of their associations. This means 
that ISUP messages to and from a particular AT are handled by the same SEM. The 
same relationship exists between TEM and SSPs. 
5 The following describes an example of a voice communication path for a basic 

two way call originating at a line, which could be a telephone or another type of 
subscriber terminal (e.g., line 507). Line 507 is connected via subscriber loop 509 to 
EO 5 1 1 , an End Office. EO 5 1 1 is connected via interoffice/toll trunk 5 1 3 to AT 5 1 5, an 
Access Tandem. An access-exit trunk 553, functioning as an access trunk, carries voice 

10 rate signals from the originating AT {e.g., AT 515) to the originating service switching 

point (c SSP1 517). If the call needs to exit at another SSP {i.e., not at the originating 
SSP). a connection over an ATM virtual circuit is built between the originating SSP {e.g., 
SSP! 517) and the terminating SSP {e.g., SSP2 533). If the call exits at the same SSP 
(i.e., at the originating SSP), then that SSP is the terminating SSP and no ATM backbone 

1 5 virtual circuit is established. For a given call, the originating Access Tandem, End 

Office, and trunks could be the same as for the terminating portion; however, the 
subscriber terminal is almost always different, i.e., one does not usually call oneself. 

On the terminating portion, access-exit trunk 553, functioning as an exit trunk, 
carries voice rate signals from the terminating SSP {e.g., SSP1 517 or SSP2 533) to the 

20 terminating Access Tandem {e.g., AT 51 5 or AT 535). From this point, the connection 

to the terminating subscriber terminal {e.g., line 539) is similar to the originating 
connections. The terminating AT {e.g., AT 515 or AT 535) is connected via 
interoffice/toll trunk 513 to the terminating End Office {e.g., EO 51 1 or EO 537), which 
is connected via subscriber loop 509 to line 539. 

25 It should be noted that SSP1 517, SAM 519, and ATM node 521 are typically in a 

switching center, such as Switch center-A 650 on FIG 6. Similarly, SSP2 533, 
SAM 531, and ATM node 529 are typically in a switching center, such as Switch 
center-C 670 on FIG. 6. It should also be noted that the configuration described above is 
for voice; however, a configuration for data or video calls in a VASP-enabled network 

30 would be similar. The differences would be in the nature of the access and exit facilities, 

which would have to match the bit rates of the data and video signals. Also, the 
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subscriber terminal device would have to have functions that could originate and 
terminate data and video calls. 

The signaling flow of a basic two-party call begins when access SEM 123 
receives an SS7 Initial Address Message ("IAM") from originating AT 515 via 
5 STP-A 501 and STP-B 503 over SS7 links 551 and sends a VASP-specific message 

along TCP/IP path 120 requesting routing and control information from MEM 105 in 
order to process the call. MEM 105 performs a query of its internal data (e.g., memory 
resident data 205) and executes service logic to determine how or if the call should be 
handled. MEM 105 sends a response message along TCP/IP path 120 to access 

10 SEM 123 that contains instructions on how to handle the call. 

Two pieces of data are returned from the MEM 105 query. One datum is a 
context indicator (i.e., a key) that links a set of messages to a particular call. This key, 
which is inserted in the ISDN User Part ("ISUP") IAM messages, is used by the SEMs 
and TEMs to keep track of the ISUP messages for each call. The other datum returned to 

15 access SEM 123 is a Virtual Routing Number ("VRN") which determines how the call is 

routed in the network. The VRN is used by one or more SSPs (e.g., SSP1 517) to select 
a trunk for the terminating portion of the call. Access SEM 123 prepares a modified 
IAM to initiate the terminating portion of the call. Access SEM 123 modifies the IAM 
by replacing the "Called Number Parameter" field with the VRN, which SSP1 517 

20 interprets as the called number. Access SEM 123 sends the IAM to SSP1 517 via SS7 

link 551. SSP1517 then performs its normal routing function as programmed by its 
internal translation and routing database, as is common with service switching points. 

The receipt of the IAM from access SEM 123 by SSP1 517 triggers a call event 
in the SSP1 517 similar to the call event in access SEM 123, i.e., a call with an 

25 originating and terminating portion. The interpretation of the VRN by SSP1 5 1 7 

determines if SSP1 5 1 7 signals TEM 1 15 or exit SEM 125 to handle the terminating 
portion of its call. If SSP1 517 determines that a connection to an AT (e.g., AT 535) 
connected to SSP2 533 is required, TEM 1 15 is signaled. If SSP1 517 determines that a 
connection to an AT (e.g., AT 515) connected to SSP1 517 is required, exit SEM 125 is 

30 signaled. For the latter case, the originating SEM (e.g., access SEM 123) may be 

signaled to perform the role of a terminating SEM. If TEM 1 15 is signaled, the call 
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requires a transport trunk implemented as a soft permanent virtual circuit ("S-PVC") in 
the ATM network to cross-connect the access trunk to the exit trunk. To service the 
terminating portion of the call in SSP1 517, TEM 1 15 queries an internal data map of 
SSP trunks to ATM trunks to acquire the endpoints of the S-PVC. TEM 115 also 
prepares and sends an IAM toward exit SSP2 533. TEM 115 examines the ISUP 
message to select a terminating SSP. TEM 115 modifies the destination point code and 
circuit identification code ("CIC") to address the selected SSP and sends the ISUP 
message to the selected SSP. 

The receipt of the IAM by SSP2 533 from TEM 115 triggers a call event in 
SSP2 533 similar to the call event in access SEM 123 and SSP1 517, i.e., a call with an 
originating and terminating portion. The terminating SSP performs a routing function 
similar to that performed by SSP1 517; however, the destination is a terminating Access 
Tandem. SSP2 533 signals exit SEM 125 to handle the call. Exit SEM 125 receives the 
IAM and restores the original called party number, selects a trunk based on the 
originating point code ("OPC") and CIC received from the terminating SSP and sends 
the ISUP message to the terminating Access Tandem which signals the terminating End 
Office. 

If the call is answerable {e.g., valid called number, available trunks along the 
terminating path) the terminating signaling points {e.g., EO 537, AT 535, and SSP2 533) 
respond with ISUP address complete messages ("ACMs"). The ACMs pass from the 
exit AT {e.g., AT 535) back through EM signaling points to the originating AT (e.g., 
AT 515). TEM 1 1 5 uses the ACM as an indication to construct the ATM VC by 
signaling the ATM nodes to tear down loopback connections and build a VC between the 
endpoints selected earlier. 

Upon receipt of an Address Complete Message ("ACM") from exit SEM 125, 
TEM 115 selects an ATM VC to carry the call between SSP1 517 and SSP2 533. The 
VC is selected based on a mapping in MEM 105 that maps TDM trunks to ATM trunks. 
This is a key interworking function that converts a narrowband facility address to a 
broadband facility address at the transport layer. The VC is not established until 
successful call setup has completed through to the end of the call path at the terminating 
subscriber line {e.g., line 539). This setup is signaled by the receipt of ANM messages 
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from exit SEM 125, which has gone through originating and terminating call setup 
sequences just as have access SEM 123 and TEM 115. TEM 115 sets up the VC by 
issuing SNMP commands to the ATM nodes. The call is established when the SS7 
ANM message has been propagated from AT 535 back along the SS7 links 55 1 through 
5 all STPs and back to exit SEM 125 and access SEM 123. 

The construction of VCs could also be done on receipt of an ISUP Answer 
Message ("ANM"), which means the call has been answered by the called party or by a 
device on behalf of the called party. The ACM is selected because it occurs earlier in the 
call and allows more time for TEM 1 15 to signal the ATM nodes. The ANM, like the 

10 ACM, passes backwards from the terminating signaling points through the EM signaling 

points, back to the originating AT, and on to the originating End Office (e.g., EO 51 1). 
At this time the voice path is "cut-through," i.e., the voice path is set up end-to-end. 

In a typical scenario, the call exists until one of the parties to the call hangs up, 
which generates an ISUP release message ("REL") which is propagated through the 

15 signaling points on the other side of the call. The REL message is an indication that the 

call should be torn down in all signaling points along the path. TEM 115 tears down the 
ATM VC if there are no other calls active on any of the DS-0 trunks of the same VC. 
The SEMs release resources (e.g., call registers, call contexts, and circuit identification 
codes) and send release complete messages to an AT which forwards them on to the an 

20 EO. Release procedures in the AT and EO are similar. Once every signaling point has 

completed its release functions, an ISUP release complete message is provided, which 
indicates the call has been dropped in all signaling points. 



DATA ARCHITECTURE 

25 Data Distribution 

The main data storage location for the VASP system is Master SMS DB 330. 
Tables in this database support SMS applications 325, LERG/LARG, transaction logs, 
SS7 and error messages, and ATM routing, network, and customer service configuration. 
Master SMS DB 330 is conceptually one database, but as those skilled in the art 

30 understand, the data stored in Master SMS DB 330 could easily be distributed among 
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multiple databases. 

Data to support MEM 105 and TEM 115 components resides in distributed 
databases (e.g., EM DB-A 610 and EM DB-B 630 described herein as active and backup 
embodiments, respectively, of EM DB 210), which coexist on servers with EM 101 
application logic. The distributed configuration of EM 101 databases provides higher 
performance data access and database fault resilience for logging activity. 

Several data structures are stored in memory resident data 205 to provide faster 
access to the routing data. These tables represent a de-normalized view of the routing 
tables stored in Master SMS DB 330 and are synchronized with Master SMS DB 330 by 
known memory replication techniques such as background data transfers or store-and- 
forward. The data refresh process is performed on scheduled time intervals or upon user 
request. 

Diabas e Sizing Estimates and Transaction Volume 

The following table summarizes the storage requirements for the EM and the 
master SMS databases in an embodiment of the invention. In such an embodiment, 
Oracle products, such as Oracle Server (RDBMS), Common Oracle Runtime 
Environment ("CORE"), and PL/SQL, are preferably used. Each row in the table 
includes the type of data that is stored, the location of storage (Oracle database vs. 
memory resident tables), which database it is stored in (EM and/or master SMS), and 
notes concerning the duration of storage. 



25 


GB per Server 

TYPE OF DATA RDBMS EM SMS 

(3 active (1 active 
servers) server) 


30 


Transaction (Current Month) Oracle 0.82 
* EM capable of 7 days Fault Resilience Storage 


10.51 




Transaction (Full History) Oracle 
* 6 month 


63.06 


35 


Transaction (Summary History) Oracle 
* 2 year (1/50 of Full History) 


1.26 
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10 



15 



Billing Administration 


Oracle 




0.03 


* 2 year (1/50 of Full History) 








Error (Current Month) 


Oracle 


0.01 


0.11 


* 1 error for every 1 00 transactions 






Error (Full History) 


Oracle 




0.63 


* 6 month 








Error (Summary History) 


Oracle 




0.01 


* 2 year (1/50 of Full History) 








LERG/LARG 


Oracle 


0.03 


0.03 


LNP (SOA & Subscriptions) 


Oracle 


0.04 


0.04 


Customer 


Oracle 




0.27 


Order 


Oracle 




0.27 


Equipment and Facilities 


Oracle 


0.02 


0.02 


Route 


Oracle 


0.47 


0.47 


Security 


Oracle - 


0.05 


0.05 


Route 


In Memory 


0.47 




Total - GB 




1.91 


76.76 



The following tables are provided as examples of the estimated distribution of 
20 transaction processing among the various VASP system components in one embodiment 

of the invention. In these estimates, a transaction refers to one database select, insert, 
update, or delete operation, or to one message. The estimates are based on the traffic 
volume indicated in the first row of the tables and assume an even distribution of call 
traffic over the network. 

25 

CONTROL PROCESSORS 



40 





Transactions per month (in millions) 






MEM TEM BPX 

1,857.143 1,142.857 71.429 


600E 

642.857 


STP/SCP 

1,000.000 






Transactions per call 






TASK 


MEM 


TEM BPX 


600E 


STP/SCP 


SS7/SNMP 


13 




7 


13 


External 


SNMP Internal 


8 1 






Routing 


3 




1 


1 


Log/Status 


8 




1 




Setup 




8 






EM Inter-Module 2 


Total - Control 26 


16 1 


9 


14 
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ADMINISTRATIVE 



5 



10 



15 



Transactions per month (in millions) 


SMS 


TOTAL/MONTH 


5.073 


4,719.359 


Transactions per Customer 


Task 


SMS 


Engineering 


0.001 


Network Analysis 


1.000 


Network Mgmt. 


0.500 


Svc. Provisioning 


0.050 


Billing Export 


1.000 


Bill Processing 


1.000 


Total - Admin. 


3.551 



20 



E>3ta Archival 

As call traffic is carried over the network, the transaction, message, and error logs 
25 increase in size. In order to manage the amount of disk storage for supporting the log 

tables, an archival procedure transfers the data to different media (e.g., tape) and 
summarizes the historical log entries into a less space intensive statistical format. 

SECURITY INFRASTRUCTURE 

30 Master SM S Database Access 

Access to Master SMS DB 330 is controlled through the definition of discrete 
views of the database. These discrete views correspond to different types of carriers, and 
provide an individual carrier access to only the data that carrier is meant to see. This 
allows an individual carrier's proprietary data to remain secure while residing on a 

35 network that is utilized by several different carriers. Some examples of views based on 

type of carrier are as follows: 
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Subscribing carriers only have access to the data that pertains to their network 
equipment and call traffic. 

Mediating carriers have access to, and are able to maintain, all of the data on the 
network. 

5 Providing carriers have access to the data that pertains to their network 

equipment, but not to the details about the call traffic that is carried on the equipment. 
Call traffic data is available in summary form only. 

System Access 

1 0 There are several levels of access into the VASP system. On the client side, there 

is an application/network level of access, based on user ID/password combinations. On 
the server side, there is both a general database level of access, and a more specific 
table/view level of access. Any password information that is sent across the network 
from client to server is encrypted to provide further security. 

15 

SERVER ARCHITECTURE 
Switching Centers 

Referring to FIG. 6, the network includes three switching centers, such as Switch 
center-A 650, Switch center-B 660, and Switch center-C 670. In some embodiments of 
20 the invention, Switch center-A 650 is located in Chicago, Switch center-B 660 is located 

in New York, and Switch center-C 670 is located in Los Angeles. When Chicago, New 
York, and Los Angeles are referred to herein, those skilled in the art will understand that 
these particular cities are used only as examples of switching center locations. 

25 Server Configuration 

As illustrated in FIG. 6, there are two types of servers in the VASP system, EM 
servers and master SMS database servers. An EM server, such as EM server-A 605, 
supports the processes that provide MEM 105, SEM 110, and TEM 1 15 functionality and 
holds a database, such as EM DB-A 610, that supports these processes. A master SMS 

30 database server, such as Master SMS DB server-A 615, supports the processes that 
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provide IEM 405 functionality and holds the master copy of the SMS database. 

As shown in FIG 6, in Switch center-A 650, the EM server-A 605 and Master 
SMS DB server-A 615 reside on different physical hardware. However, as those skilled 
in the art will appreciate, any number of hardware configurations could support the EM 
and master SMS database servers. For example, both EM server-A 605 and Master 
SMS DB server-A 615 could exist on the same physical platform. Alternatively, either 
EM server-A 605 or Master SMS DB server-A 615 could be distributed across multiple 
physical platforms. In addition, element managers do not necessarily have to run on the 
servers specified above {e.g., IEM 405 could run on an EM server.) 



Fault Resilience Supp ort 

The VASP system achieves fault resilience as a system through a combination of 
hardware and software solutions. One active EM server is located in Switch 
center-A 650. A backup {i.e., standby) EM server, such as EM server-B 625, is located 

15 in Switch center-B 660. A backup of EM DB-A 610 is maintained in EM DB-B 630, 

which resides on EM server-B 625. In one embodiment of the invention EM relies on 
the DGM&S OMNI platform to provide the architecture for active/backup fault 
resilience and switchover of processing control. Also in this embodiment, Sun E6000 
servers are utilized at both the active and backup sites. As those skilled in the art know, 

20 other server hardware and methods for achieving fault resilience are possible. 

Similarly, one active master SMS database server is located in Switch 
center-A 650 (e.g., in Chicago), with one backup master SMS database server, such as 
Master SMS DB server-B 635 located in Switch center-B 660. Embodiments of Master 
SMS DB 330 include an active master SMS database {e.g., Master SMS DB-A 620) and 

25 backup master SMS database {e.g., Master SMS DB-B 640). Thus, a backup of Master 

SMS DB-A 620, which resides on Master SMS DB server-A 615, is maintained in 
Master SMS DB-B 640, which resides on Master SMS DB server-B 635. In one 
embodiment of the invention, Unix utilities and standard backup features of relational 
database management systems provide the architecture for active/backup fault resilience 

30 and switchover of processing control. Also in this embodiment, Sun E6000 servers are 

utilized at both the active and backup sites. As those skilled in the art know, other server 
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hardware and methods for achieving fault resilience are possible. 

As with the active EM and master SMS database servers, those skilled in the art 
will appreciate that other hardware configurations could support the backup EM and 
master SMS database servers. Further, other geographic locations for the backup servers 
5 are possible. For example, the backup servers could be at Switch center-C 670 or, as an 

another alternative, the backup servers could be at the same location as the active servers. 

VASP PRODUCTION ENVIRONMENT 
ATM Network Con figuration 

10 T^ee primary switching centers (NY, Los Angeles, Chicago) and five remote 

switching centers exist in the network. Each switching center contains a BPX switch, 
which is linked to the MFS Worldcom network, in a ring of bandwidth, through a BPX 
switch at both a collocate space and a Worldcom POP. The three main backbone trunks 
between the primary switching centers exist as pre-provisioned PVCs across the network. 

15 Each Access Tandem switch is serviced by one of the 600E switches, such that the 600E 

performs the routing for all of its call traffic. Calls that are routed between primary 
switching centers are carried over one of the backbone trunks, while those that originate 
and terminate within the same switching center are not. 

The SS7 traffic on the network is routed by a mated pair of STPs located in 

20 Chicago and New York. Messages routed between switching centers is carried over the 

backbone trunks, on a PVC that is dedicated to SS7 traffic, while all other messages are 
carried over an external SS7 network. 

The EM components are distributed such that an active MEM 105/ TEM 1 1 5 
exists in the Chicago switch center, and a backup MEM 105/ TEM 115 exists in the New 

25 York switch center. Master SMS DB 330 is also deployed in an active/backup 

configuration, with the active database in Chicago and the backup in New York. 

Communication Architecture 

The following describes an embodiment of the invention, with reference to 
30 FIG. 8. Each primary communication network switching center (e.g., Switch 
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center-A 650) links into a Worldcom POP (e.g., POP 813) through a collocate space 815. 
BPX switches (e.g., ATM node 521 and ATM node 529) are located in each of the three 
switching centers (e.g., Chicago, Los Angeles, New York) and in collocate space 815 and 
the Worldcom POP (e.g., POP 813). An OC3 (e.g., optical 155 Mbs) connection (e.g., 
transport trunk 557) runs between the switching center and collocate space 815, and a 
DS3 connection (e.g., transport trunk 557) runs between collocate space 815 and the 
Worldcom POP (e.g., POP 813). Bandwidth for these connections over the Worldcom 
ring (e.g., ring 81 1), are pre-provisioned into PVCs to provide the main ATM backbone 
trunks for carrying the call traffic and to support LAN/WAN and SS7 communication 
between the switching centers. 

The communication network switching centers and the collocate spaces contain a 
number of AXIS shelves (e.g., SAMs 519 and SAMs 531) with DS3 connections (e.g., 
transport trunk 557) to a BPX switch (e.g., ATM node 521 and ATM node 529). The 
AXIS shelves (e.g., SAMs 519) in the switching centers have several DS1 connections 
(e.g., access-exit trunks 553) into a 600E switch (e.g., SSP1 517), while the AXIS 
shelves (e.g., SAMs 531) in collocate space 815 have DS1 connections (e.g., access-exit 
trunks 553) to a multiplexer (e.g., MUX 809). The MUX 809 functions to group the DS1 
connections into DS3 connections to the Access Tandem (e.g., AT 515 and AT 535) 
switches that are serviced by the switching center. The BPX and 600E switches and the 
AXIS shelves are pre-provisioned to create access trunks, such that a CIC on the Access 
Tandem will map directly to a CIC on the 600E. Additional pre-provisioning is 
performed such that a CIC on the 600E maps directly to a CIC on a 600E in another 
switching center, with the backbone trunk management to support this path being 
controlled dynamically by VASP system components. 

The STPs (e.g., STP-B 503) in the switching centers (e.g., Chicago and New 
York) route the SS7 message traffic between the Access Tandem and 600E switches and 
MEM 105 components. These messages are received either from a gateway to the SS7 
network 220 or over the network, through a PVC dedicated to SS7 traffic between the 
switching centers. SS7 links 551 connect STPs (e.g., STP-B 503) to SS7 network 220, 
600E switches (e.g., SSP1 517), and EM server- A 605. An ATM connection provided 
by an AXIS shelf (e.g., SAM 519) provides the transport for SS7 link 551. 
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A dedicated WAN, including router 805 and hub 807, supports communication 
between an active EM in Chicago and a backup EM in New York, as required for fault 
resilience by the distributed OMNI architecture. An additional, and logically separate, 
WAN is in place between TEM 1 1 5 and the BPX switches for ATM route set up and tear 
down, and between VASP system components and Master SMS DB-A 620 for 
transaction logging and data synchronization. OAM&P functions performed at a 
Network Control Center 801 are enabled by User interface 472 (accessed at client 470) 
and WAN TCP/IP links and LAN TCP/IP links. TCP/IP paths 120 connect Network 
Control Center 801, router 805, hub 807, and ATM node 521. TCP/IP paths 120 also 
connect hub 807 to Master SMS DB Server-A 615 (including Master SMS DB-A 620) 
and to EM server- A 605 (including EM DB-A 610). Access to Master SMS DB-A 620 is 
supported by a TCP/IP WAN, using Data Access Layer 160 to provide messaging and 
middleware. 

It will be appreciated by those skilled in the art that further embodiments of the 
invention may be made without departing from the spirit and scope of the invention as 
described herein. Such embodiments are intended to be within the scope of the appended 
claims. 
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CLAIMS 

What is claimed is: 

1 1 . A method for providing enhanced communications services in conjunction with a 

2 communications network, comprising the steps of: 

3 collecting information in real-time concerning a transaction traversing the 

4 network; 

5 storing the transaction information in a database; and 

6 accessing the stored information from the database in real time. 

1 2. The method of claim 1, further comprising the step of analyzing a portion of the 

2 stored information in real-time. 

1 3. The method of claim 1 , wherein the collected information relates to an entire 

2 transaction, from beginning to end. 

1 4. The method of claim 1, wherein the stored information includes all of the 

2 information contained in Call Detail Records. 

1 5. The method of claim 4, further comprising the step of creating a Call Detail 

2 Record from the stored information. 

1 6. The method of claim 2, wherein the stored information is analyzed in order to 

2 efTectuate the maintenance of the network. 

1 7. The method of claim 2, wherein the stored information is analyzed in order to 

2 effectuate billing administration. 

1 8. The method of claim 7, wherein the stored information is analyzed to determine 

2 the billing for an entire transaction. 
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9. The method of claim 8, wherein the step of analyzing the stored information to 
determine the billing for an entire transaction is done immediately after the 
transaction occurs. 

10. The method of claim 2, wherein the stored information is analyzed to determine 
real-time usage of the network resources. 

1 1 . The method of claim 1 0, further comprising the step of re-routing overflow traffic 
on the network based on the analyzed information. 

12. The method of claim 1, wherein the database is a normalized relational database. 

13. The method of claim 2, wherein the information is analyzed in order to effectuate 
network engineering. 

14. An apparatus for providing enhanced communications services in conjunction 
with a communications network, comprising: 

a network for carrying transaction data; 

an element manager coupled to the network for collecting, in real-time, 

information concerning the transaction as it traverses the network; 

a database linked to the element manager for storing the information 
collected by the element manager; and 

an interface for accessing the stored information from the database in 
real-time. 

15. The apparatus of claim 14, further comprising a processor coupled to the interface 
for analyzing the stored information. 
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